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ADAPTER FRAMEWORK 

CROSS REFERENCE TO RELATED APPLICATIONS 

This application claims priority to U.S. Provisional Patent Application No. 
filed on December 13, 2002. 

BACKGROUND 

[ 0002 ] The following description relates to business systems, for example an 
exchange infrastructure for collaborative business systems. 

[0003] Companies face an increasing need for integration of and collaboration among 
their information and enterprise software systems. In most current system landscapes, many 
components are directly connected in a one-to-one relationship with other components, with 
the integration capabilities hardwired into the application components and individual 
mappings programs. Under these conditions, collaborative sharing of information or process 
control is difficult if not impossible. Upgrades, changes, or extensions to an infrastructure of 
directly connected components are challenging and resource-intensive. 

[0004] Electronic business collaboration, however, increasingly requires connectivity 
among all applications inside and outside of company boundaries. Networks such as the 
Internet provide opportunities for systems to communicate almost instantly with other 
systems or individuals. Business processes that once were restricted to intranets and their 
users are now moving to the Internet to become an effective composition of Web services. A 
Web service is a programmable, self-contained, self-describing, modular application ftinction 
that can be published, discovered or invoked through an open Internet standard. 

[0005] New open protocols and standards like the hypertext transfer protocol (HTTP) 
and extensible markup language (XML) provide universal connectivity among different 
messaging systems, however a challenge of technical connectivity can remain, particularly 
with some legacy systems. A mechanism is needed that can automatically bridge a technical 
connectivity gap and adapt to various messaging interfaces. 
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SUMMARY 

[0006] This document provides an infrastructure to establish connectivity among 
applications. The infrastructure includes an adapter framework that includes one or more 
messaging adapters. Adapters provide connectivity from and to a central integration server 
for applications that cannot do so directly. In particular, the integration server sends and 
receives simple object access protocol (SOAP) messages over HTTP, according to which the 
adapters connect message-sending applications that employ a different protocol. In one 
implementation, the adapters provide Java messaging service (JMS), JDBC, file I/O and a 
generic SOAP handler over HTTP. 

[0007] In one aspect, a framework for communicating between central message 
exchange server and one or more heterogeneous extemal data sources includes an adapter 
engine. The adapter engine includes one or more adapters. Each adapter is configured to 
connect, via messaging, an extemal data source operating using a native message fomiat and 
the central message exchange server using an extensible markup language (XML) messaging 
format. In an implementation, the adapter engine is a pure Java (J2SE) application, which 
offers standards for database access, queue systems and generally guarantees platform 
neutrality. 

[ 0008 ] The Adapter Engine includes no persistence layer, and therefore employs a 

synchronous connection to the integration server at runtime. A transactional processing 
(guaranteed delivery) of the adapters is implemented for asynchronous messages and 
discussed in more detail below. 

[0009] In accordance with another aspect, a method for communicating between 
central message exchange server and one or more heterogeneous extemal data sources is 
disclosed. The method includes instantiating an adapter based on a message format used by 
the extemal data source. The adapter is configured to communicate with the central message 
exchange server via XML. The method fiuther includes connecting the extemal data source 
to the central message exchange server via the adapter, and commxmicating data between the 
extemal data source and the central message exchange server through the adapter. 
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[0010] The details of one or more embodiments are set forth in the accompanying 
drawings and the description below. Other features, objects, and advantages will be apparent 
from the description and drawings, and from the claims. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[ 0011 ] These and other aspects will now be described in detail with reference to the 
following drawings. 

[ 0012 ] FIG. 1 is a block diagram of an exchange system for integrated, message- 
based collaboration. 

[0013] FIG. 2 is a block diagram of an exchange infrastructure. 

[0014] FIG. 3 is a block diagram of an integration repository, integration directory, 
and runtime engine for collaborative processing. 

1 0015 ] FIG. 4 is a block diagram illustrating a process for communicating a )single 
message between two applications. 

[0016] FIG. 5 is a block diagram of an adapter framework for collaborative 
messaging. 

[ 0017 ] FIG. 6 is a flow diagram illustrating data processing in an inbound adapter 
from an external data source to the integration server. 

[0018] FIG. 7 is a flow diagram illustrating data processing in an outbound adapter 
from the integration server to an external data source. 

[0019] Like reference symbols in the various drawings indicate like elements. 

DETAILED DESCRIPTION 

[0020] The systems and techniques described here relate to an adapter framework for 
communicating between a centralized message exchange and a number of extemal systems 
that employ various communication standards and protocols. 
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[0021] FIG. 1 is a simplified block diagram of a system 100 for integration and 
"loose coupling" (i.e. message-based interaction) of applications. The system 100 includes 
an exchange infrastructure (XI) 1 10 for collaborative processing among internal components 
(ICs) 102 of an enterprise, and between extemal components (ECs) 104 that communicate to 
one or more ICs 102 through a firewall 105. The ICs and ECs 102 and 104 represent any of 
a number of processes or services and their software and hardware, such as Web portals, 
buying or seUing programs, electronic mail, business management programs, project 
planning programs, etc., and are preferably Web-based applications. Each of the ICs/ECs 
102, 104 communicates via messaging with one or more other components according to at 
least one of a number of communication protocols or standards. 

[0022] ITieXI 110 is a self-contained, modularized exchange platform for driving 
collaboration among the components 102, 104. The XI 1 10 includes a central integration 
repository and directory storing shared collaboration knowledge. The XI 1 10 supports open 
standards such as various standard markup languages like the extensible markup language 
(XML), web service description language (WSDL), and simple object access protocol 
(SOAP) to provide an abstraction of technical interfaces for the components 102, 104, and 
for message-based communications across heterogeneous component interfaces. The self- 
contained, modularized functions of the XI 1 10 can be provided as one or more Web services 
based on standard Intemet technology, and therefore can be published, discovered, and 
accessed within a network of components 102, 104 using open standards. 

[0023] FIG. 2 illustrates a system landscape 200 including an XI 1 1 0 for facilitating 
message-based collaboration among appUcations. The exchange infrastructure 110 includes 
an integration repository 202, an integration directory 204, a system landscape directory 203, 
and an integration server 206. The integration repository 202 captures design-time 
collaboration descriptions of all software components that can conamunicate via the XI 1 10. 
The integration directory 204 captures configuration-specific collaboration descriptions of 
the system landscape 200 at runtime, which includes accessing actual component 
installations from the system landscape directory 203 and connectivity descriptions for 
extemal components, all of which represents the shared business semantics of the system 
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landscape 200. The integration server 206 uses the shared business semantics at runtime to 
execute message-based collaboration among the active software components. 

[0024] The integration server 206 includes a runtime engine 2 1 4 that provides 
messaging and business process control at runtime for connecting services and managing the 
process flow of value chains. The integration server 206 also includes integration services 
216 that typically require an application-specific implementation. Like the integration 
repository 202 and integration directory 204, the integration server 206 is configured for 
deployment within any existing system infirastructure. The integration server 206 is 
preferably a dedicated server that applies the shared collaboration knowledge of the 
integration directory 204 of the supported system landscape in a runtime collaboration 
environment. A runtime workbench 208 allows organizations or users to manage the reliable 
operation of the XI 1 10. 

[0025] The XIllO also includes various adapters 209 that may be included within an 
adapter fi^amework (not shown) that enables connectivity between the integration server 206 
and proprietary applications 211, Web-based services 213, and third party applications 215. 
The adapters 209 serve as a bridge to coimect extemal data sources to the integration server 
206. The adapter firamework may include general services available for all adapters, as 
described in further detail below. These general features include connectivity between 
extemal components and XI 1 10 components, transactional processing support, remote 
configurabihty, and monitoring, logging, and error handling. 

[0026] The XI 1 1 0 can also include Web applications server 2 1 0 that provides Web- 
based applications programmed according to standard computing platforms using web- 
specific programming languages such as Java and ABAP, for instance. The Web 
appUcations server 210 also includes an instance of the runtime engine 214 for providing 
messaging and business process control between Web-based applications such as Java 
applications 220 and ABAP applications 222, and other components. 

[0027 ] New interfaces for software components can be defined using an appHcation 
component employing a proxy, which allows the interface for the software component to be 
implemented locally in the XI 1 10. Proxies make the communication technology stack 
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transparent to applications, and present an application with a programming language- 
dependent interface. The proxies can be generated by a proxy generator 218 based on 
information stored on the integration repository 202. The proxy generator 218 uses the 
interface information described via a standard Web-based language such as WSDL and 
XSDL to create platform- and programming language-dependent code in the application 
development system. The communication logic can be implemented based on the proxy that 
represents the interface description of the respective development platform, such as Java, 
ABAP, and .NET for the web-based applications 213. The proxies convert platform-specific 
data types into XML and provide access to the component-specific local runtime engine. On 
the outbound side, proxies are generated completely. Outbound proxies can be called via a 
service invocation provided by an application's developer. On the inboxmd side, only proxy 
skeletons need to be generated, as implemented by the receiving application. 

[0028] FIG. 3 illustrates the integration repository 202, the system landscape 
directory 203, the integration directory 204 and an instantiation of the runtime engine 214 in 
greater detail. The integration repository 202 includes design-time business processes 232, 
routing objects 234, mappings 236, and interfaces 238, all of which are defined according to 
one or more business scenarios 230. The integration repository 202 accesses descriptions of 
all software components 240 in the system landscape from the system landscape directory 
203. The business scenarios 230 of the integration repository 202 describe and configure 
message-based interaction between application components or enterprises. An enterprise can 
select one or more business scenarios described in the integration repository 202 as a best 
practice for rapid configuration of the XI 1 10. 

[0029] The business processes 232 can be implemented as extensible compound Web 
services executed using a business process engine 274. Each business process 232 is 
modeled centrally in the integration repository 202, and can defined to the detail of user 
interaction steps. A company or user designs each business process 232 according to its 
business needs, independently of the technical implementation. There may be several 
categories of business process templates: i.e. generic business processes, industry-specific 
processes, and company-specific processes, for example. Each process identifies the Web 
services that are needed and that must be interconnected. In one specific implementation, 
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business processes 232 are defined using a graphical interface, and then stored in a 
standardized format like Business Process Modeling Language (BPML). The business 
process engine can then interpret these models and execute them to drive collaboration 
among software components. 

[ 0030 ] Routing objects 234 are pointers that point to a specific part of a message. 
They are predefined criteria to determine potential receivers of messages that must be 
distributed between components and business partners during collaborative processing, 
hiformation about the routing objects is used for receiver determination. Mappings 236 
define required transformations between message interfaces 238, message types, or data 
types in the integration repository 202. These transformations cover structural conversions 
and value mappings. Structwal conversions are used for semantically equivalent types that 
are syntactically or structurally different, whereas value mapping may be used when an 
object is identified by different keys in multiple systems. In a specific implementation, a 
graphical mapping tool is provided to assist in mapping, and transforming data is based on 
the Extensible Stylesheet Language Transformation (XSLT) or Java code. 

[ 0031 ] The integration repository 202 is the central point of entry for interface 
development, storage and retrieval, and includes interfaces 238 that describe all message 
interfaces of all software components in the system landscape. Accordingly, the interfaces 
238 can be implemented on any software component using any technology. In one 
implementation, the interfaces 238 are based on WSDL. Message interfaces are made up of 
message types, which are in turn made up of data types. The data types can be described 
using XML Schema Definition Language (XSDL). An example of a data type is "address," 
which is used in the message type "Create PO" and can be reused for the message type 
"Create Invoice." Interfaces 238 can be arranged according to any classification, such as 
inbound and outbound, or synchronous and asynchronous. 

[0032] The components 240 represent component descriptions that include 

information about application components, as well as information relating to their 

dependencies on each other. In a specific implementation, the component descriptions are 

based on the standard Common Information Model (CIM) of the Distributed Management 

Taskforce. Since the integration repository 202 includes design-time information, only 
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component-type information, independent of actual installation, is stored as components 240 
in the system landscape directory 203. The component descriptions can be added using an 
API or interactively using a graphical user interface. 

[0033 ] The integration directory 204 details information from the integration 
repository 202 that is specific to the configuration of each component as installed in the 
system. The configuration-specific collaboration descriptions of the integration directory 
204 can be generated automatically from content in the integration repository 202 or 
manually by a user using a graphical user interface. In one implementation, the integration 
directory 204 is built on a Java platform and its content is represented via XML using open 
iQtemet standards. The integration repository 202 can be upgraded without affecting the 
integration directory 204 or any runtime collaborative processes. The user then decides 
which changes should be transferred to the integration directory 204, either as predetermined 
automatic upgrades or manually via graphical tools. 

[0034] The integration directory 204 includes configuration-specific descriptions of 
business scenarios 250, business processes 252, routing rules 254, and executable mappings 
256. The integration directory 204 also includes descriptions of active Web services 258, 
and active business partners 260. The integration directory 204 uses a description of the 
active system landscape 262 firom the system landscape directory 203. The business 
scenarios 250 in the integration directory 204 represent the overall view of the interaction 
among interfaces and mappings 256 in the context of the actual configuration relevant for the 
specific implementation. The business processes 252 represents an executable description of 
all active business processes. 

[0035] The routing rules 254 determine the receivers of a message on a business 
level. In one specific implementation, the content of a message is used as a routing rule 254. 
Other parameters may also be used. Relevant input parameters include the sender, the sender 
message type, the message to identify the receivers, and the receiver message type. The 
routing rules 254 can be described declaratively using XML Path Language (Xpath, i.e. by 
using a graphical tool) or can be coded in Java or use routing objects 234. The runtime 
engine 214 at runtime accesses information on the routing rules 254. 
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[0036] The routing rules 254 may use logical terms to describe senders and receivers 
in order to separate them from the physical address provided by the Web services 258 
described in the integration directory 204. The physical address can therefore be changed 
without changing business-oriented content. Mappings 256 in the integration directory 204 
represent mappings required in the active system landscape, in contrast to the integration 
repository mappings 236 that contains all supported mappings. Some new entries however, 
such as a new sequence of mappings, can be made only in the integration directory 204 to 
address additional Web services for mapping, for example. The runtime engine 214 accesses 
the integration directory mappings 256 at runtime. 

[ 0037 ] Web services 258 describe interfaces implemented within the current active 
system landscape, as well as active Web services supported by described business partners 
260. As such, information describing Web services 258 can be exchanged with UDDI- 
compatible directories or added manually. Each Web service 258 description also provides 
physical addressing details, access information, and other special attributes such as uniform 
resource locator (URL), protocol, and security inforaiation. In one implementation, the Web 
services 258 are described in WSDL, and SOAP and ebXML are used as messaging 
protocols. The runtime engine 214 accesses information about the Web services 258 at 
runtime as well. 

[ 0038 ] The system landscape 262 of the system landscape directory 203 describes the 
current system landscape that uses the XII 10. The system landscape 262 describes which 
components are installed and available on certain machines within the system, which 
instance or client was chosen, further information on the installed components, other system 
landscapes, and so on. The system landscape 262 description is based on an open 
architecture and can adhere to any widely accepted standard such as CM. Thus, many 
proprietary and third party components can be configured to automatically register 
themselves in the system landscape 262 upon being installed within the actual system 
landscape. Access interfaces to the system landscape 262 description can be based on open 
standards as well, such as the Web-based Enterprise Management (WBEM) and SOAP 
standards. 
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[0039] Business partners 260 defines information for business partners of an 
enterprise, such as names, addresses, and URLs, but may also contain more detailed and 
sophisticated information. For instance, the business partners 260 may include a description 
of the message formats that can be directly received and processed, or of security protocols 
used for safe communications, or trading terms that are employed in the partnership. The 
kind of information stored in business partners 260 can be govemed by enterprise-specific 
decisions of the enterprise using the XI 1 10. 

[0040] The integration directory 204 and the runtime engine 214 form a collaborative 
runtime environment for executing collaborative business processes. The collaborative 
runtime environment provides all runtime components relevant for exchanging messages 
among the connected software components and business partners. The integration server 206 
executes the collaborative runtime environment or Web appUcation server 210, either of 
which can include an instance of the runtime engine 214 in accordance with informational 
resources provided by the integration directory 204. 

[ 0041 ] The runtime engine 214, which exchanges all messages between the various 
interconnected components, includes two layers: an integration layer 272 and a messaging 
and transport layer (MTL) 280, The integration layer 272 includes a business process engine 
274 executing centrally modeled business processes, a logical routing service 276 and a 
mapping service 278. The MTL 280 provides a physical address resolution service 282, a 
messaging and queuing service 284, a transport service 286 via HTTP, and a database 288. 
The integration services 216 in the integration server 206 can support the runtime engine 
214. An MTL 280 is also included in each instantiation of the runtime engine 214 in Web 
applications servers 210, as well as m each adapter 209 of the adapter fi-amework connecting 
to various software components. Each MTL 280 has a role in the execution of the EO 
protocol, as will be explained fiirther below. 

[ 0042 ] At runtime, business processes 252 are instantiated and executed by the 
business process engine 274, which executes the respective Web services described in Web 
services 258 independent of their location according to the business process model. The 
business process engine 274 is independent of the semantics of the executed business 
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processes 252, and is configured as a mediator and facilitator for business processes 252 to 
interact with technical components of the runtime system landscape. 

[ 0043 ] FIG. 4 is a block diagram illustrating several functions of the runtime engine 
214 in a process of exchanging a message between applications. A sending application 303 
resides in a sending component system 302, which represents the hardware and software 
platform of the sending application 303. One or more receiving applications 305 each reside 
in a receiving component system 304. A conmiimication path for a message 310 can include 
an outboimd proxy 307 at the outbound interface from the sending component system 302, 
through the runtime engine 214 and adapter 309 to the receiving component system 304. A 
receiving component system 304 may also utilize an inbound proxy 311 rather than an 
adapter. The configuration and connectivity of the shown receiving component systems 304 
is merely exemplary, and it should be noted that such configuration and connectivity could 
take any nvunber of forms. The pictured example illustrates both asynchronous and 
synchronous communication. In synchronous communication, routing and physical address 
resolution is only needed for the request as the response is transferred to the sender, which is 
already known. 

[ 0044 ] With reference also to FIGS. 2 and 3, for a given message the logical routing 
service 276 uses information on the sending application and the message interface to 
determine receivers and required interfaces by evaluating the corresponding routing rules, as 
shown at 312. The routing rules are part of the configuration-specific descriptions of the 
runtime system landscape provided by the integration directory 204, and can be implemented 
as Xpath expressions or Java code. The mapping service 278 determines the required 
transformations that depend on message, sender, and sender interface, as well as the receiver 
and receiver interface, at 314. In the case of asynchronous communication, even the message 
direction is determined to appropriately transform input, output, and fault messages. 

[0045] After retrieving the required mapping from the integration directory 204, the 
mapping service 278 can either execute XSLT mappings or Java code (or any combination in 

a given sequence) to the content of the sent message. Below the integration layer, 

messaging, queuing, and transport services 284 move the message to the intended or required 

receiver(s). After the message is transformed into the format expected by each receiver, the 
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physical address of the required receiver service and other relevant attributes are retrieved 
from the integration directory 204 and mapped to the message, at 316. 

[0046] A queuing engine in the messaging and queuing service 284 stores ingoing, 
outgoing, erroneous, and work-in-progress messages persistently. The messaging layer of 
the runtime engine 214 provides queuing ftinctions for the physical decoupling of application 
components and guarantees messages are delivered exactly once according to a protocol (i.e. 
the "EO protocol"). The transport service 286 enables the runtime engine 214 to act as both 
an HTTP client and server. The transport service 286 implements an HTTP client that 
enables outbound communication and an HTTP server that handles inbound communication 
by accepting incoming documents. Additional server functions can address situations in 
which the receiver has no HTTP server by supporting polUng over HTTP. 

[ 0047 ] As discussed above with reference to FIG. 2, the XI 1 10 employs a nxmiber of 
adapters 209 in an adapter framework for connecting with application components 211,213 
and 215 in the system landscape 200. The adapters 209 enable the runtime engine 214 to talk 
to different application components in accordance with any number of communication 
standards. FIG. 5 shows an adapter framework 500 in more detail. The adapter framework 
500 includes an adapter engine 502, a server application that hosts one or more adapter 
instances of one or more adapter types. The adapter engine 502 can be implemented as a 
pure Java (J2SE) application, and can be hosted on any one of a number of operating 
systems. The adapter engine 502 includes no persistence layer, therefore synchronous 
connection to the integration server 206 is required at runtime. 

[ 0048 ] Each adapter instance has a logical, imique name, and can be configured, 

created, started, stopped and terminated inside the adapter engine 502. Any nimiber of 

adapters can be hosted inside the adapter engine 502, although preferably by default at 

configuration time one inbound/outbound adapter pair (i.e. messages into and out of the 

integration server 206, respectively) is instantiated for each requested adapter type. For 

instance, if an adapter is instantiated for a particular fi le type, by default the adapter engine 

will instantiate an inbound file adapter 510 for receiving inbound message files, and an 

outbound file adapter 51 1 for transmitting outbound message files. The adapters can include 

JDBC adapters 512, IMS adapters 515, and/or their inbound/outbound pair. Other adapters 
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can be configured for simple SOAP, Idoc, RFC, and plain HTTP message types. The correct 
outbound and/or inbound adapter can be selected dynamically via different types of 
endpoints. For example, a special type of outbound adapter could be activated using only the 
configuration of endpoints in the integration directory. The parameters necessary for calling 
a receiver, for instance, are at least a part of the endpoint (i.e. port, host, and/or destination) 
and one or more security objects. 

[0049] The adapter engine 502 hosts several base services that are used for or by all 
hosted adapters. The services can be started at the adapter engine 502 startup time. The base 
services include a GUI engine 520 that implements a HTTP(S) server for a browser 504 user 
interface (UI). The services also include an adapter monitor 522 for dispatching the 
incoming configuration, administration and monitoring tasks fi-om the UI. The adapter 
monitor 522 can be implemented with generic access to all adapter engine, adapter and 
service configuration parameters. 

[0050] Other services include an RtcMonitor 524 that handles requests sent firom the 
runtime workbench 208, such as ping and self-test requests, as described fiuther below. An 
information log (InfoLog) 526 is a service that handles all monitoring information presented 
in the UI for each running adapter. An identification log (EDLog) 578 tracks message 
identifiers (messagelDs) captured by adapters in an "Exactly Once (In Order)" mode. The 
IDLog can be a small, tile-based database used for the message identifier tracking. A 
password tokens (Pwtokens) 530 service provides for replacement of passwords in any 
adapter configuration with a token. At runtime, the PWtokens 530 service replaces the 
tokens with the real passwords on the fly. The passwords can be collected in an extemal tile- 
based database in a scrambled format. 

[0051 ] A system landscape directory access (SLD access) 532 service connects to 
system landscape directory 203 of the XI installation. Once configured, it registers the 
adapter fi-amework 502 and its adapters at startup time, and the adapters may use the service 
at runtime for read access to the system landscape directory 203. A HTTP(S) Client/Server 
service includes an HTTP(S)-Server implementation for all outbound adapter types (i.e. 
retrieving messages fi-om the integration server 206). The server can be configured to use 
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basic authentication, and to act as an HTTP- or HTTPS-Server. For the inbound adapter 
types, HTTP or HTTPS requests can be sent to the integration server, respectively. 

[ 0052 ] The adapter engine 502 supports a number of protocol types used by the 
integration server 206, such as "Best Effort," "Exactly Once" (EO), and "Exactly Once In 
Order" (EOIO). In EO/EOIO mode, all adapters are configured to guarantee that incoming 
messages from the Integration Server are persisted exactly once in a connected data source 
540, and that outgoing messages read from the data source 540 are processed exactly once in 
the integration server 206, respectively. The adapter engine 502 does not include a 
persistence layer for the transported messages themselves, but does include a persistency 
used by all adapters for storing state information describing the processing state of a 
message. 

[0053 ] When installed inside a system landscape, the adapter engine 502 may register 
itself in the system landscape directory 203. With this, the adapter framework becomes 
"visible" within the central XI monitoring tool, the runtime workbench 208. From the 
runtime workbench 208, availability and checks ( such as ping and self-test) can be 
performed, and installation information can be retrieved. The configuration UI of the adapter 
engine 502 is also accessible through the runtime workbench 208. 

[ 0054 ] Once the adapter engine 502 is started, any standard Internet browser 504 can 
connect to configuration services via an adapter framework core 536 to run adapters and 
handle administration tasks. A user may initialize, start, stop, configure, terminate, and view 
monitoring information of each installed adapter via control mechanism 538. Detailed trace 
files may be stored for analysis purposes. A test environment may also be provided with 
basic test options for the adapter I/O check. All settings are available with common Intemet 
browsers 504 for remote or local administration and monitoring. The adapter configurations 
may be stored locally inside the adapter framework core. 

[ 0055 ] As a prerequisite for the central monitoring and administration, any adapter 
engine 502 running inside an XI landscape can connect itself directly to the system landscape 
directory 203 of the XI installation and report its basic configuration data to the system 
landscape directory 203. In addition to writing information to the system landscape directory 
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203, the adapters may also read information from the system landscape directory 203 for 
centralized configuration. Inbound adapters may also query the association between a sender 
and the integration server 206 from the system landscape directory 203, retrieving the URL 
endpoint of the integration server 206 from this query. 

[0056] The runtime workbench 208 can display any number of adapter engines 502 
that have registered to the system landscape directory 203. The runtime workbench 208 can 
be configured to perform a variety of fimctions with each adapter engine 502, including but 
not limited to, display the adapter instances installed on the adapter engine, run a heartbeat 
(i.e. ping) check on the adapter engine for availability of the adapter engine and/or adapter 
instance(s), run a self-test on the adapter engine, and read out basic system settings of the 
adapter engine's host. In addition to these integrated fimctions, the runtime workbench 208 
can start the configuration GUI of the adapter engine 502 to provide access to all 
administration options, including log entries of the adapters from the IDLog 528. 

C 0 057 ] Adapter-specific errors uiclude configuration errors and runtime errors. Both 
types of errors can be reported in the adapters' log information. If an adapter cannot be 
initialized due to errant configuration information (i.e. configuration error), it cannot be 
started. If an adapter can be started but is unable to process a message (i.e. runtime error), it 
will automatically do a retry on the message after a specified interval. However, if the reason 
for this runtime error is a configuration problem, it will have to be configured properly and 
then restarted manually to proceed error-free. 

[ 0058 ] FIG. 6 is a flow diagram illustrating data processing in an inbound adapter 
600 from an extemal data source 602 to the integration server 206. At block 604, data is read 
or extracted from the extemal data source 602 is performed, whereby the inbound adapter 
602 polls its extemal data source 602 or is triggered if data is available. PoUing is conducted 
if, for example, the extemal data source 602 is a file system and the adapter 600 is a file 
adapter, or a database for a JDBC adapter. Triggering can occur if, for example, the extemal 
data source 602 includes a IMS event and the adapter 600 is a JMS adapter, or an HTTP 
request occurs for a SOAP adapter. 
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[0059] At block 606, the retrieved data may be converted from a format native to the 
external data source to a format used by the integration server, such as XML. Depending on 
the configuration of the system landscape and the XI, conversion may be optional. For 
instance, file and JMS adapters may receive external data formats that are not XML but can 
be formatted very easily (e.g., a file with simple csv-format or fixed column lengths). Also 
simple data structures that include separated, different formats can be recognized and 
formatted. In the latter case, an additional step using a XML-rendering, which needs little or 
no additional meta data configuration information, can be provided by the adapter 600 to 
produce an XML payload. Under this scenario, a file adapiter can also generate a file split, 
wherein a file may be split up in several record sets, each sent as an independent message to 
the integration server 206. Also, this scenario can be enabled under the "Exactly Once" 
protocol so that no part of a document will be lost or duplicated if the processing is 
interrupted during the file split. In a JDBC adapter, a JDBC resultset can be converted to an 
XML stream by default. A SOAP adapter and the JMS adapter may invoke additional, free 
defined conversion classes. 

[0060] At block 608, data (converted or not) is sent to the integration server 206. 
This step includes generating a message that confomis to a protocol used by the XL This 
message will includes the data as a payload, and use an HTTP client to send the message 
over HTTP(S) to the integiation server 206 at block 612. If a quality of service type "Exactly 
Once (In Order)" (EO/EOIO) is specified for the message, the message identifier is persisted 
at block 610 and used to retry sending the message in case of a failure at block 608. If the 
message is sent successfiiUy to the integration server 206, a confirmation acknowledgement 
is processed at block 610 to prevent the data from being sent again in another message. 

[0061] FIG. 6 is a flow diagram illustrating data processing in an outbound adapter 
618 from the integration server 206 to an external data source 602. As illustrated by block 
620, each outbound adapter is registered to a unique service of an HTTP server, and receives 
the messages that the integration server 206 sends to the URL associated with the HTTP 
server. Data is then received and extracted from the message at block 622, and in the case of 
an EO/EOIO message type, the message identifier is extracted for EO/EOIO handling at 
block 624. 
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[ 0062 ] At block 626, a conversion from an XI format to a format native to the 
external data source 602 can be executed. As discussed above, depending on the 
configuration of the system, conversion is optional. File and JMS adapters may format 
simple-structured XML documents to text files consisting of csv- or fixed-length columns 
and filled rows. Also simple structures containing different formats can be formatted to csv 
formats. In a JDBC adapter, a specific XML-document format is expected that can be 
converted to an SQL-INSERT statement for a specified database table. A SOAP adapter and 
a JMS adapter may invoke additional, free defined conversion classes. 

[0063] At block 628, the data is written to the extemal data source, and the message 
is marked as processed in the case of an EO processing mode. If an error occurs, the error is 
reported back to the integration server 206, and the niessage can be sent repeatedly until 
processing is reported as successfiil. 

[0064] Various implementations of the systems and techniques described here can be 
realized in digital electronic circuitry, integrated circuitry, specially designed ASICs 
(application specific integrated circuits), computer hardware, firmware, software, and/or 
combinations thereof. These various implementations can include implementation in one or 
more computer programs that are executable and/or interpretable on a programmable system 
including at least one programmable processor, which may be special or general purpose, 
coupled to receive data and instructions from, and to transmit data and instructions to, a 
storage system, at least one input device, and at least one output device. 

[0065] These computer programs (also known as programs, software, software 
applications or code) include machine instructions for a programmable processor, and can be 
implemented in a high-level procedural and/or object-oriented programming language, and/or 
in assembly/machine language. As used herein, the term "machine-readable medium" refers 
to any computer program product, apparatus and/or device (e.g., magnetic discs, optical 
disks, memory, Programmable Logic Devices (PLDs)) used to provide machine instructions 
and/or data to a programmable processor, including a machine-readable medium that receives 
machine instructions as a machine-readable signal. The term "machine-readable signal" 
refers to any signal used to provide machine instructions and/or data to a programmable 
processor. 
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[0066] To provide for interaction with a user, the systems and techniques described 
here can be implemented on a computer having a display device (e.g., a CRT (cathode ray 
tube) or LCD (liquid crystal display) monitor) for displaying information to the user and a 
keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide 
input to the computer. Other kinds of devices can be used to provide for interaction with a 
user as well; for example, feedback provided to the user can be any form of sensory feedback 
(e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be 
received in any form, including acoustic, speech, or tactile input. 

[0067] The systems and techniques described here can be implemented in a 
computing system that includes a back-end component (e.g., as a data server), or that 
includes a middleware component (e.g., an application server), or that includes a front-end 
component (e.g., a client computer having a graphical user interface or a Web browser 
through which a user can interact with an implementation of the systems and techniques . 
described here), or any combination of such back-end, middleware, or front-end components. 
The components of the system can be interconnected by any form or medium of digital data 
communication (e.g., a communication network). Examples of communication networks 
include a local area network ("LAN"), a wide area network ("WAN"), and the Internet. 

10068] The computing system can include clients and servers. A client and server are 
generally remote from each other and typically interact through a communication network. 
The relationship of client and server arises by virtue of computer programs running on the 
respective computers and having a client-server relationship to each other. 

[0069] Although a few embodiments have been described in detail above, other 
modifications are possible. Portions of this disclosure discuss operation though a portal, but 
any of a number of access systems and methods may be used to manage collaboration 
sessions. The logic flows depicted in FIGS. 6 and 7 do not require the particular order 
shown, or sequential order, to achieve desirable results. Other embodiments may be within 
the scope of the following claims. 
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